-
Notifications
You must be signed in to change notification settings - Fork 415
Deploy RRGraphBuilder
in RRGraph Clock Builder to replace the use of rr_node_indices
#1801
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@mithro Not sure why the Yosys+ODINII strong tests always failed in a few second. The artifact log file is empty. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @tangxifan . Looks generally good, but I have some suggested changes / comments (none too major).
vpr/src/device/rr_spatial_lookup.cpp
Outdated
return sink_nodes; | ||
} | ||
|
||
/* By default, we always added the channel nodes to the TOP side (to save memory) */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment looks wrong (talking about channels).
This code also points out why we should rework the underlying rr_node_indices implementation; it's strange to have a multi-dimensional array matrix where some dimensions must always be accessed with a specific index. Hopefully that is on your near-term agenda Xifan. Could put a TODO in to refactor that way, if you think such a comment would be a useful reminder.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the typo. Just fixed it.
I think it will be a good time to rethink the rr_node_indices
data structure once all the related APIs are replaced.
Actually, it is not too far. I expect only we need another 2 pull requests, before fully shadowing the current rr_node_indices
.
I put a TODO to remind us during the refactoring. I will take a deep look into the rr_node_indices
data structure and propose something.
vpr/src/device/rr_spatial_lookup.cpp
Outdated
} | ||
|
||
for (const auto& node : rr_node_indices_[SINK][x][y][node_side]) { | ||
if (RRNodeId(node)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could comment this to say you're inserting only the valid ids in the returned vector.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree. Added the comment.
vpr/src/device/rr_spatial_lookup.h
Outdated
* | ||
* Note: | ||
* - Return an empty list if there are no sinks at the given (x, y) location | ||
* - The node list returned only contain valid ids |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo: contain -> contains
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for pointing it out. Fixed.
|
||
return node_index; | ||
return size_t(node_index); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we change the return type of this function to RRNodeId and remove the cast? (May have to change the calling function too some then).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just checked the dependency of this API. It is used only by another API. It is simple change. Done.
// However, since the SINK node has the same xhigh/xlow as well as yhigh/ylow, we can probably use a shortcut | ||
for (int ix = rr_graph.node_xlow(node_index); ix <= rr_graph.node_xhigh(node_index); ++ix) { | ||
for (int iy = rr_graph.node_ylow(node_index); iy <= rr_graph.node_yhigh(node_index); ++iy) { | ||
node_lookup.add_node(node_index, ix, iy, rr_graph.node_type(node_index), rr_graph.node_ptc_num(node_index), SIDES[0]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like we use SIDES[0] to insert the sink node, and look for it later on the TOP side. Hence should we use TOP consistently or SIDES[0] consistently to make sure this is always in alignment? I assume SIDES[0] == TOP so this all works, but it still seems dangerous as if anyone ever edits the order of SIDES we'd subtly break code written this way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree. We should not expose the side argument to developers because they may feel confused.
You are right on the SIDE[0] which is actually the TOP side. This convention has been there for a while (I do not know who introduced it). I am o.k. to change it if necessary.
Indeed, developers may mess up.
For example, they added a channel node to the BOTTOM side but in find_node(), it will always search the TOP side.
vtr-verilog-to-routing/vpr/src/device/rr_spatial_lookup.cpp
Lines 23 to 29 in c06800f
e_side node_side = side; | |
if (type == IPIN || type == OPIN) { | |
VTR_ASSERT_MSG(side != NUM_SIDES, "IPIN/OPIN must specify desired side (can not be default NUM_SIDES)"); | |
} else { | |
VTR_ASSERT_SAFE(type != IPIN && type != OPIN); | |
node_side = SIDES[0]; | |
} |
However, I think it is not a good idea to force the developers to give a dummy side when addethe API. I modified the API so that the side option will have a default value (SIDE[0]) if not specified. In client functions, I remove all the usage of the SIDE[0] for non-IPIN/OPIN nodes.
@@ -320,7 +319,7 @@ void ClockToPinsConnection::create_switches(const ClockRRGraphBuilder& clock_gra | |||
|
|||
//Create edges depending on Fc | |||
for (size_t i = 0; i < clock_network_indices.size() * fc; i++) { | |||
clock_graph.add_edge(rr_edges_to_create, clock_network_indices[i], clock_pin_node_idx, arch_switch_idx); | |||
clock_graph.add_edge(rr_edges_to_create, clock_network_indices[i], size_t(clock_pin_node_idx), arch_switch_idx); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we change the function prototype to avoid the cast (send in an RRNodeId instead)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See my reply in a previous comment on the t_rr_edge_info
//TODO: CHANX uses odd swapped x/y indices here. Will rework once rr_node_indices is shadowed | ||
rr_graph_builder.node_lookup().add_node(chanx_node, iy, ix, rr_graph.node_type(chanx_node), rr_graph.node_ptc_num(chanx_node), SIDES[0]); | ||
} | ||
} | ||
|
||
return node_index; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider changing return type to RRNodeId, and directly making node_index an RRNodeId (and therefore wouldn't need chanx_node).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I believe, we can use the API add_node_to_all_locs()
as you suggested in another PR #1800. These for loops will be replaced by a simple line:
rr_graph_builder.add_node_to_all_locs(chanx_node)
I leave a TODO comment here to remind me to finish the API replacement after PR #1800 is merged.
Let me know if this is fine for you.
Note: the Yosys+Odin-II failure is an expected, unrelated failure and is not gating. |
…Add comments about TODO action items;
…void duplicated codes
Looks good; thanks. |
Description
This PR focuses on updating RRGraph clock builder functions, where we use the refactored data structure
RRGraphBuilder
to replace the legacy data structurerr_node_indices
.This PR aims to eliminate the use of
rr_node_indices
in the RRGraph clock builder, as one step further in deprecating the legacy data structure.Checklist:
find_sink_nodes()
toRRSpatialLookup
rr_node_indices
for RRGraph Clock Builderrr_graph2.cpp
which are replaced by built-in APIs inRRSpatialLookup
Related Issue
Motivation and Context
This pull request is a follow-up PR on the routing resource graph refactoring effort #1779
How Has This Been Tested?
After the previous PR #1779 , we start reworking all the source files that use the legacy data structure
rr_node_indices
in a high priority, in order to deprecate the legacy data structure as soon as possible.Current statistics on the files that use
rr_node_indices
(in total there are 143 lines related):This PR will remove the use in
Types of changes
Checklist: